Most modern computer systems employ operating systems (OSs) that support graphical user interfaces (GUIs). Generally, the OS renders and presents content on a display device via a GUI using a graphics rendering and animation (GRA) infrastructure.
An application (e.g., a messaging application, a calendar application, a photography application, etc.) may be developed to include rules and/or assumptions that are received as input by a GRA infrastructure. These rules/assumptions enable the GRA infrastructure to render and present the application's GUI objects in an OS's GUI (a GUI implemented by a computer system executing an OS is referred to herein as a “system GUI”). Additionally, these rules/assumptions may prevent the application's GUI objects from being manipulated by the computer system and/or OS such that the application's GUI objects are presented in a specific manner via the system GUI. Manipulation of GUI objects includes, but is not limited to, transforming the GUI objects between locations in the system GUI, blurring a GUI object, resizing a GUI object, scaling a GUI object, and changing the opacity/transparency of a GUI object.
For an illustrative example, a messaging application may be developed to include rules and/or assumptions that prevent one of the application's GUI objects from being moved from a first location to a second location within a system GUI. For this example, the computer system executing the OS may be capable of presenting the application's immovable GUI object as being moved from the first location to the second location even though the application's rules/assumptions prevent such an operation. One way such a presentation is achieved is by capturing a snapshot or screenshot of the application's immovable GUI object, moving the snapshot to the new location in the system GUI, rendering the snapshot in its new location, and presenting an image of the snapshot in its new location. For a real-world example, when a multimedia message that includes an image is presented on a touchscreen display of computer system (e.g., a smartphone, a tablet computer, a laptop computer, etc.), a force touch input may be used to “pop” the image out of the received message (i.e., enlarge the image, overlay the enlarged image on the rest of received message, and blur all GUI objects below the enlarged image). For this example, the messaging application may include rules/assumptions that prevent the image in the received image from being moved within the system GUI (i.e., from being “popped”). For this example, the OS may enable the system GUI to “pop” the image by taking a snapshot of the image and processing the snapshot to achieve “pop” effect.
One problem with the use of snapshots in system GUI operations is that such snapshots increase the amount of computational resources required for presenting a system GUI. Specifically, each snapshot and its subsequent presentation in a system GUI requires memory, processing power, and the like. Also, the required amount of computational resources increases as time progresses. This is because there may be a requirement to capture multiple snapshots of the same application's GUI object as time progresses given that an appearance of the application's GUI object within a system GUI may change over time. Furthermore, the use of a snapshot is limited to a specific type of media—a non-moving image captured at a specific time instance (e.g., a photograph, etc.). Snapshots are not suitable for other types of media—e.g., video, audio, live photographs, GIFs, etc.—that progress over a time duration (i.e., a plurality of time instances).
In one scenario, an application's GUI objects are rendered and presented on a display device using a CORE ANIMATION® GRA infrastructure. CORE ANIMATION® is available on both Apple's iOS and OS X® for use by developers to animate the views and other visual elements of their applications. In this and other GRA infrastructures, every snapshot creates at least one new node in the GRA's infrastructure's layer and/or render trees. Consequently, the layer and/or render trees will progressively require more computational resources as additional snapshots are captured and manipulated (e.g., memory, processing power, etc.). For example, as the sizes of the layer and render trees increase due to the additions of new nodes for each snapshot, additional memory is required for storage of the trees and additional processing power is required to process the growing trees.